Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 54.79%. Comparing base (6243b56) to head (bfe3538).
Report is 16 commits behind head on master.

@@            Coverage Diff             @@
##           master    #2160      +/-   ##
==========================================
+ Coverage   54.63%   54.79%   +0.15%     
==========================================
  Files         583      583              
  Lines       78507    79110     +603     
==========================================
+ Hits        42895    43350     +455     
- Misses      32399    32487      +88     
- Partials     3213     3273      +60     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@r3v4s Can you pull in the latest master?

@zivkovicmilos @thehowl
Adding more metadata in event struct by default brings pros and cons.

Here is my new suggestion

1. Remove Type. I really can't find meaningful usage for this specified type data. (Perhaps Name would be more to determine which event)

2. Keep current pkgPath, Func, OrigCaller and prev. For observability I think these for values are least required ones.

3. PrevFunc is tricky. I wanted bring more observability only by just examining event datas, not bunch of other datas from another rpc end points. But if this is too much for general point of view, we can get rid of it.

Okay, I've had a discussion with Milos with what to do here.

Essentially, I don't think there is a compelling case for adding PrevRealm nor PrevFunc. PrevFunc shouldn't be necessary (also I think it's buggy, but anyway); PrevRealm contains information which if it is really useful to the reader of the events, they can just be passed in as attributes. (That's the whole point of attributes).

Reading your last comment;

Here is my new suggestion

1. Remove `Type`. I really can't find meaningful usage for this specified `type` data. (Perhaps `Name` would be more to determine which event)

2. Keep current `pkgPath`, `Func`, `OrigCaller` and `prev`. For observability I think these for values are least required ones.

3. `PrevFunc` is tricky. I wanted bring more observability only by just examining event datas, not bunch of other datas from another rpc end points. But if this is too much for general point of view, we can get rid of it.

I tend to agree on 2. For 3, I don't think PrevFunc or PrevRealm are useful, so just scrap them.

Type: we can change it to name, but having worked with event systems like this in the past, I know it's useful. If you're using Go, it allows you to have the name parsed as a string, and the attributes as a json.RawValue; then switching what to unmarshal the RawValue depending on the value of the type.

We can change it to name; but I think Type is fine too.

This is how I see this PR right now:

• We can close, or:
• Change Type to Name; and please, bring it back to the top of the struct (and put attributes next to it, instead of at the bottom)